Turnbull China Bikeride/Turnbull China Bikeride - Disc 1.iso/HENSA/MATHS/PLPLOT/PLPLOT.ZIP/doc/Xauthority

Text File | 1994-04-08 | 25.7 KB | 611 lines

IMPORTANT NOTE about the plplot Tcl/TK driver :

    IF YOU DO NOT HAVE XAUTH STYLE SECURITY ENABLED, YOU ARE VULNERABLE TO
    OUTSIDE INTRUSION.  I MAKE NO CLAIMS THAT PLPLOT/TK IS SAFE AGAINST
    SUCH AN ATTACK, AND ASSUME NO RESPONSIBILITY FOR RISK.

To reiterate the statement made elsewhere:

    There is no warranty or other guarantee of fitness of this software.
    It is provided solely "as is". The author(s) disclaim(s) all
    responsibility and liability with respect to this software's usage or
    its effect upon hardware or computer systems.

OK, now for some clarification.  The Tcl7.0/TK3.3 release attempts to
improve security by using the Xauthority mechanism (there are other ways
but this was a quick fix).  To use it, you must either deal with the new
access control method or compile Tcl/TK with security off.  It's not
really a big deal using the new access method but can be anything from
only mildly confusing initially to a major pain in the neck.

This file contains various comments, tricks, tips, explanations, or
anything else I could dig up on Xauthority.  xauth-style security really
does represent a big improvement over xhost-based access, since xhost
leaves you open to intrusion from anyone on the machine you are granting
access to.  With conventional X applications, the danger is not so great
(IMO), for it would take a fairly sophisticated trojan horse to exploit
the security leak (a fake xterm, for example).  But Tcl/TK changes the
nature of this game completely.  The incredible power offered by Tcl/TK
means much potential for evil as well as good.  I will tell you how badly
you can be hacked, since the hackers presumably already know this.

Say you grant xhost access to a machine where someone wishes to do you
harm.  This person starts up a "wish" (TK windowing shell) connected
to your machine, but modified to not display an actual window so as
to not raise your suspicions.  A "show interps" command (or something
like that) displays the names of the Tcl interpreters that your Tcl/TK
applications are using.  Then the hacker merely needs to send commands
to these interpreters to do nasty things, the classic being "exec rm -rf
*".  Yes, this is a legal Tcl command.

Using xauth this is prevented.  You can also prevent it by renaming the
dangerous commands in your interpreter to {} (null), thus preventing their
use altogether.  In fact I do this in plserver.tcl, but prior to plplot
4.99e I had neglected to do it in the TK driver's interpreter as well,
meaning I still wasn't safe.  This was an oversight on my part, but a very
easy one to make, meaning you'd best exercise some caution.  If you do NOT
have the Tcl/TK xauth security feature enabled (it is possible to compile
Tcl/TK with it turned off), and also grant xhost access, you'd best know
whether or not your TK apps are hack-resistant.  My renaming the "exec"
and "open" commands (the latter can be done only after all autoloading
takes place) takes care of the two most flagrant examples of security
holes, but there may be others, so caveat emptor.

Before too long I will also support the Tcl-DP method (sockets) for
communication between the client and the renderer.  Fortunately, the
issue of security was recently taken up in earnest by the Tcl-DP author
as well, so I don't see any reasons not to pursue this right away (except
lack of time).  This will allow better operation of the tk driver across
slow networks, as well as actually running the renderer on a different
machine as the client.

So here is my quickie explanation of how to get Xauthority working.
I had no trouble on our HP X terminals, but lots on the console.  Your
mileage may vary.  If you have extreme problems, yell at your vendor,
but if you only grant xhost access to secure machines then you might
also consider compiling Tcl/TK without the security feature.

---------------------------------------------------------------------

First, you need to have a file ~/.Xauthority.  If you already have this,
you are off to a good start.  In this case your X server is already set to
use xauth style security.  If not, you need to create a ~/.Xauthority
file.  You can do this by running "xauth" and then making entries.  You
will need to reset the X server for this change to take effect.  If you
are at the console this may mean a reboot (my HP running VUE gave me a bit
of a hard time).

You next disable all xhost based access.  This means not only typing
"xhost -", but deleting all hosts named as having access when you
type "xhost".

Finally you ftp your ~/.Xauthority file to your home directory on the
machine you are running client X applications.  When they start up, they
will try to create windows on your local server as specified by DISPLAY
(or whatever).  The client and server then exchange magic cookies, and
when they match, the client gains access and is allowed to make X
requests.

Note that you may in general need to ftp your ~/.Xauthority file to the
desired hosts each session, because at least on my machine the X server
writes a new magic cookie in ~/.Xauthority each time it is run.  This
is basically analogous to reenabling xhost access each time you log in.

-----------------------------------------------------------------------

Below I've appended another person's explanation of what needs to be done,
as posted on comp.lang.tcl.

-----------------------------------------------------------------------

Author: Vivek Khera <[e-mail]>        -*- text -*-
Subject: making your X server more secure
Originally Written: Tue, 10 Jul 90 12:26:15 -0400
Time-stamp: "August 10, 1993 12:28:31"

Here's how I have made my X sessions more secure than just the xhost
way.  It is mostly transparent, and doesn't allow arbitrary users to
plaster windows on my screen, or to snoop at my keyboard.  Even people
who log into the machine I'm working on can't connect to the server.

This whole scheme is based on the MIT-MAGIC-COOKIE scheme, where each
client must present to the server a magic cookie to prove that it is
allowed to connect.  The cookie is kept in a file in your home
directory (.Xauthority) which only you are allowed to read.  The
server reads this file when it starts up, so if you change the cookie
file, you will have to restart the server to make it read the new
information.  Normally you don't need to do this.  The .Xauthority
files can be merged using the xauth program.  See the man page for
some more details.

Here is how to make yourself "secure":

1. Create a .xserverrc file similar to mine in your home directory.
The important part is to pass the "-auth $HOME/.Xauthority" option to
the X server on the last line.  Here is what my .xserverrc file looks
like:

--cut here--
#!/bin/sh
# for Xsun:
# -ar1 NNN    set keyboard repeat delay to NNN milliseconds
# -ar2 NNN    set keyboard repeat rate to NNN milliseconds

if test -w /dev/cgthree0 -o -w /dev/cgsix0; then
  server=Xsun
else
  server=XsunMono
fi

# we *must* do an exec for the server so that signals are handled properly
exec $server -ar1 250 -ar2 20 -auth $HOME/.Xauthority
--cut here--


2. Before you start the X server, be sure to create the .Xauthority
file.  I wrote a shell script to do this, called newcookie.  You must
create a new .Xauthority file when you switch machines, as the name of
the machine the server is on is part of the authority mechanism.  This
is how it knows which cookie to send to which server it is connecting
to.  I run newcookie from my .login file when I am logging into the
console.  If you run newcookie after you start the X server, you are
hosed unless you can remember the random number it generated and
recreate the .Xauthority file by hand; otherwise you will have to quit
and restart the server.

Here is my newcookie program.  If you have a program that generates
md5 signatures, you can use it to generate a strong random number by
passing the -md5 flag.  If you have md4, just edit the script to use
it instead of md5.  If you don't have md4 or md5, then it assumes you
have perl to generate random numbers.  If you don't have perl, then
write your own program to generate a long random number with an even
number of hexadecimal digits in it, and then run "xauth add" like in
my program.  Note that md4 and md5 generate values that an even number
of digits long already.  An implementation of md5 can be found in
Internet RFC 1321.

--cut here--
#!/bin/sh

# create new .Xauthority file

PATH=/usr/local/X/bin:/usr/gnu/bin:$PATH

# try some security
auth=$HOME/.Xauthority
#cp /dev/null $auth

# generate a nice long random key
if [ "$1" = "-md5" ]; then
  # use a random noise source and get a strong checksum of it.
  # this is probably a stronger random number than the other method.
  key=`pstat -pfS | md5`
else
  # quick and dirty.  can probably be recreated if time can be guessed.
  key=`perl -e 'srand; printf int(rand(100000000000000000))'`
  # use $key$key to make sure even length.
  key=$key$key
fi
# add to auth file.
xauth add ${HOST}/unix:0 . $key
xauth add ${HOST}:0 . $key
--cut here--

3. Make sure any program you run does not do an xhost +<machine>
command.  This will destroy any security you might gain by using
xauth.  Notably, the rcmd script does this.

4. Start the X server using startx.  Things should be secure now.  All
new X clients (from R4 and later) understand this authorization
scheme, so you should never need to run xhost again. (Unless you are
using the standard Ultrix libraries -- but then you get what you
deserve.)  In fact, xhost should report *no* hosts as being allowed
in.

-----------------------------------------------------------------------

Here's the (not very helpful) information I got from the man pages:

-----------------------------------------------------------------------

From X(1):

 ACCESS CONTROL
      An X server can use several types of access control.  Mechanisms
      provided in Release 5 are:
      Host Access            Simple host-based access control.
      MIT-MAGIC-COOKIE-1        Shared plain-text "cookies".
      XDM-AUTHORIZATION-1        Secure DES based private-keys.
      SUN-DES-1            Based on Sun's secure rpc system.

      vuelogin/Xdm initializes access control for the server, and also
      places authorization information in a file accessible to the user.
      Normally, the list of hosts from which connections are always accepted
      should be empty, so that only clients with are explicitly authorized
      can connect to the display.  When you add entries to the host list
      (with xhost), the server no longer performs any authorization on
      connections from those machines.    Be careful with this.

      The file from which Xlib extracts authorization data can be specified
      with the environment variable XAUTHORITY, and defaults to the file
      .Xauthority in the home directory.  vuelogin/Xdm uses
      $HOME/.Xauthority and will create it or merge in authorization records
      if it already exists when a user logs in.

      If you use several machines, and share a common home directory across
      all of the machines by means of a network file system, then you never
      really have to worry about authorization files, the system should work
      correctly by default.  Otherwise, as the authorization files are
      machine-independent, you can simply copy the files to share them.  To
      manage authorization files, use xauth.  This program allows you to
      extract records and insert them into other files.  Using this, you can
      send authorization to remote machines when you login, if the remote
      machine does not share a common home directory with your local
      machine.    Note that authorization information transmitted ``in the
      clear'' through a network file system or using ftp or rcp can be
      ``stolen'' by a network eavesdropper, and as such may enable
      unauthorized access.  In many environments this level of security is
      not a concern, but if it is, you need to know the exact semantics of
      the particular authorization data to know if this is actually a
      problem.


From Xserver(1):

 SECURITY
      The sample server implements a simplistic authorization protocol,
      MIT-MAGIC-COOKIE-1 which uses data private to authorized clients and
      the server.  This is a rather trivial scheme; if the client passes
      authorization data which is the same as the server has, it is allowed
      access.  This scheme is inferior to host-based access control
      mechanisms in environments with unsecure networks as it allows any
      host to connect, given that it has discovered the private key.  But in
      many environments, this level of security is better than the host-
      based scheme as it allows access control per-user instead of per-host.

      In addition, the server provides support for a DES-based authorization
      scheme, XDM-AUTHORIZATION-1, which is more secure (given a secure key
      distribution mechanism), but as DES is not generally distributable,
      the implementation is missing routines to encrypt and decrypt the
      authorization data.  This authorization scheme can be used in
      conjunction with XDMCP's authentication scheme, XDM-AUTHENTICATION-1
      or in isolation.

      The authorization data is passed to the server in a private file named
      with the -auth command line option.  Each time the server is about to
      accept the first connection after a reset (or when the server is
      starting), it reads this file.  If this file contains any
      authorization records, the local host is not automatically allowed
      access to the server, and only clients which send one of the
      authorization records contained in the file in the connection setup
      information will be allowed access.  See the Xau manual page for a
      description of the binary format of this file.  Maintenance of this
      file, and distribution of its contents to remote sites for use there
      is left as an exercise for the reader.

      The sample server also uses a host-based access control list for
      deciding whether or not to accept connections from clients on a
      particular machine.  This list initially consists of the host on which
      the server is running as well as any machines listed in the file
      /etc/Xn.hosts, where n is the display number of the server.  Each line
      of the file should contain an Internet hostname (e.g.
      expo.lcs.mit.edu.)  There should be no leading or trailing spaces on
      any lines.  For example:

          joesworkstation
          corporate.company.com

      Users can add or remove hosts from this list and enable or disable
      access control using the xhost command from the same machine as the
      server.  For example:

          %  xhost +janesworkstation
          janesworkstation being added to access control list
          %  xhost +
          all hosts being allowed (access control disabled)
          %  xhost -
          all hosts being restricted (access control enabled)
          %  xhost
          access control enabled (only the following hosts are allowed)
          joesworkstation
          janesworkstation
          corporate.company.com

-----------------------------------------------------------------------

Here's the responses from readers of comp.lang.tcl to my frenzied cry
for help:

-----------------------------------------------------------------------

From [e-mail] Mon Sep 13 15:53:33 1993
From: [e-mail] (Ashok Singhal)
Newsgroups: comp.lang.tcl
Subject: Re: New security "feature" in Tk 3.3
Date: 11 Sep 1993 01:23:36 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: [e-mail]
NNTP-Posting-Host: duckjibe

I managed to get "send" tk3.3b2 to work with a non-local X server after some
initial difficulties with xauth (now there's a poorly documented utility; took
me several readings of the man page to figure out how to use it, what hex keys
were, no cross references, ...)

My set up: application is running on a Sparcserver 1000  running Solaris 2.3,
X server (i.e. display) is a SS10 running OpenWindows 3

I had xhost- based authorization set up initially, I disabled it and
used xauth.  Didn't work.

I shut down and restarted the window system on the server
and set up xauth again and it worked.

I have no idea why/how it did not work the first time and worked after
I restarted the window system.

- Ashok Singhal
Sun Microsystems


From [e-mail] Mon Sep 13 15:53:35 1993
Newsgroups: comp.lang.tcl
From: [e-mail] (Scott Schwartz)
Subject: Re: New security "feature" in Tk 3.3
In-Reply-To: [e-mail]'s message of 11 Sep 1993 01:23:36 GMT
Nntp-Posting-Host: roke.cse.psu.edu
Date: Sat, 11 Sep 1993 02:12:10 GMT

[e-mail] (Ashok Singhal) writes:
   I have no idea why/how it did not work the first time and worked after
   I restarted the window system.

The X server needs to be started with the ``-auth authfile'' flag.  If
you create that file and then restart, the openwin script will notice it
and invoke the X server with the right parameters.  (Under MIT X, See
the Xserver and Xsecurity manpages.)


From [e-mail] Tue Sep 14 11:51:35 1993
From: [e-mail] (Maurice J. LeBrun)
Newsgroups: comp.lang.tcl
Subject: Re: New security "feature" in Tk 3.3
Date: 14 Sep 93 11:35:21
Organization: The University of Texas at Austin
NNTP-Posting-Host: dino.ph.utexas.edu
In-reply-to: [e-mail]'s message of Sat, 11 Sep 1993 02:12:10 GMT
Status: RO


Thanks to all who replied.  I have xauth-style access control working
perfectly on my HP 720 running HPUX 9.01 and VUE 3.0 now.

For most people, the steps:
    - create the ~/.Xauthority file or make sure it exists
    - ftp ~/.Xauthority to the remote host
    - disable xhost access

worked fine, so (still having no luck on the system console) I tested it
on a nearby X-terminal, and it worked just fine.

[e-mail] (Scott Schwartz) writes:

   [e-mail] (Ashok Singhal) writes:
      I have no idea why/how it did not work the first time and worked after
      I restarted the window system.

   The X server needs to be started with the ``-auth authfile'' flag.  If
   you create that file and then restart, the openwin script will notice it
   and invoke the X server with the right parameters.  (Under MIT X, See
   the Xserver and Xsecurity manpages.)

This was the key.  After poring through the documentation I found I needed
to uncomment the line:

# Vuelogin*authorize:         True

in the file /usr/vue/config/Xconfig.  But it still wouldn't work, because
the X server needed to be restarted.  I thought specifying

Vuelogin*terminateServer:       True

would do the job, but it didn't (the X server is normally started by init
during bootup).  So I rebooted the machine.  After that, it worked fine.

Quite a lot to go through!  Since the release of Tk3.3 will have this
security mechanism set by default, it would be a good idea to include a
note about getting xauth-style access working on HP's running HPUX/VUE.

--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From [e-mail] Fri Sep 17 15:01:21 1993
From: [e-mail] (Maurice J. LeBrun)
Newsgroups: comp.lang.tcl
Subject: Re: New security "feature" in Tk 3.3
Date: 17 Sep 93 01:02:08
Organization: The University of Texas at Austin
Distribution: comp
NNTP-Posting-Host: dino.ph.utexas.edu
In-reply-to: [e-mail]'s message of 14 Sep 93 08:55:31 GMT
Status: RO

[e-mail] (Inge Wallin) writes:

   [e-mail] (Maurice J. LeBrun) writes:

   >In a previous article, I wrote:

   >   OK, my first cut at getting up under Tk 3.3b3 result in no major
   >   problems save one: unauthorized attempts to connect.  This is due
   >   to the new security check.  Turns out if ANY hosts are enabled by
   >   the older xhost mechanism, the Tk send command aborts.
   [deleted]
   >   Hopefully I am doing something wrong.  Any suggestions?

   Actually, I am very happy that things are as you described.  I have
   written a few programs using tcl/tk, and the send feature was the
   thing that almost made me have second thoughts.  It is such a gigantic
   security hole that I nearly skipped tk altogether.  However, in the
   end, the ease of use of tcl/tk made me use it anyhow.

Well, the point was I couldn't get it to work, period!  Kind of useless
in that case, eh?  Turns out that getting xauth-style security working
involves a bit of voodoo sometimes, or so it seems.

I agree about the security hole.  One of the first things I do in
my initial Tcl script is the following:

    rename exec {}
    rename open {}

I keep it right after any initial autoloads that I expect, but it
still is a pain in the butt.

   What I would like to have is a way to enable a program to receive
   sends.  If this was not used, the program would refuse to execute
   sends from other applications.  One way to do this could be to use
   "send enable" to enable the send command.

Right, me too.  It wouldn't be too hard to add such a capability.  I read
that the favored approach is to have "secure" interpreters; one would
communicate by TK send, but not execute -- it would pass what it receives
(filtered?) to your internal interpreter.  Or something like that, it may
be in the workshop proceedings.  Due out next release?

   Inge Wallin
   [e-mail]
   Dept. of EE
   Linkoping University
   Sweden

--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From [e-mail] Wed Sep 15 22:43 CDT 1993
Received: by dino.ph.utexas.edu
    (1.37.109.4/16.2) id AA05880; Wed, 15 Sep 93 22:41:29 -0500
From: Maurice LeBrun <[e-mail]>
Return-Path: <[e-mail]>
Subject: Re: New security "feature" in Tk 3.3
To: [e-mail]
Date: Wed, 15 Sep 93 22:41:29 CDT
Full-Name: Maurice LeBrun
Cc: [e-mail]
In-Reply-To: <[e-mail]>; from "Paul E. Raines" at Sep 15, 93 5:52 pm
Mailer: Elm [revision: 70.85]
Status: RO

>
> I hope you can help me.
>
> I can't get Xauthority to work and the man pages explain
> nothing. I am not trying to do anything with Tk yet, just get
> it to work in general.

I sympathize.  I was there, and it is VERY frustrating.

> I did
>     xauth add $DISPLAY . 12345678901234567890123456789012
>
> All the machines at this site share the same home directory.
> So I logged in remotely to anther machine and tried to run
> an X app, but it was refused.
>
> I restarted X, but still the same problem.
>
> I restarted with
>     startx -auth ~/.Xauthority
>
> but X refused to run complaining
>     /a/juno/u1/ra/raines/.Xauthority: ^DO@l^A0^RMIT-MAGIC-COOKIE-1^P^R4Vx^R4Vx^R4Vx^R:  not found.
>
> What am I doing wrong?

Sounds like it should work.  I did, however, leave out one part of my
tale.  I started out creating the ~/.Xauthority entry for my machine much
like you did.  I ended up rebooting my machine twice in all, and at some
point it "noticed" I wanted to use ~/.Xauthority and started creating
entries automatically upon login.  After the *next* time I rebooted (just
to be sure the X server was reset; I had no idea how to do it otherwise
using HP VUE), the access control worked!

The new entries it started creating look like the following:

dino.ph.utexas.edu:0  MIT-MAGIC-COOKIE-1  382f5...
dino/unix:0  MIT-MAGIC-COOKIE-1  382f5...
dino/unix:0  MIT-MAGIC-COOKIE-1  382f5...

The only entry I added was the first, but all three always share the same
hex key.  Dunno why it added it twice.  And I've checked; every time I log
in now I get a new hex key.  (Is this starting to resemble black magic
yet?)

Maybe this can help, maybe not.  Maybe you need to chant and juggle some
rubber chickens in front of the console :-).  It's stuff like this that
makes me wonder if I really understand computers after all..

--
Maurice LeBrun    [e-mail]
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From [e-mail] Mon Nov 15 00:41:17 1993
Newsgroups: comp.lang.tcl,comp.windows.x
From: [e-mail] (Doug Hughes)
Subject: Re: FINAL xauth ( on X-Terminals
Followup-To: comp.windows.x
Nntp-Posting-Host: happy.vf.ge.com
Reply-To: [e-mail]
Organization: GE Aerospace - VF
Date: Fri, 12 Nov 1993 13:16:43 GMT

In article <[e-mail]>, [e-mail] (Helmut Schumacher) writes:
> Does anyone have/use X-Terminals with Xauthority?
>
> How must XDM be configured?
>
> Can xauth be used without using XDM?
>
> Helmut Schumacher
>
> [e-mail]

Well, I don't think this is the right newsgroup (comp.lang.tcl) so I'm
cross-posting to comp.windows.x with followup redirected there. Anyway,
yes, we use xauth for our NCD xterminals. You have to do to things, you
have to have your xauth keys in two different places.

1) /usr/lib/X11/xdm/xdm-keys
where entries look like this
-Ethernet-00:00:a7:11:c9:c7     0xb0b125abe7cd00

2) and entry in the configuration file (this would be xterminal specific)

on our NCD's running 3.1 software the entry looks like this in the ncd's
configuration file
login-xdm-authentication-key = 0xb0b125abe7cd00

Hope this helps (notice, the two keys are identical. very important. :) )

--
_____________________________________________________________
Doug Hughes
System/Net Admin - Martin Marietta Aerospace, Valley Forge, PA
[e-mail]    or    [e-mail]